[アップデート] 32秒でパフォーマンス回復!Aurora PostgreSQL でクラスタキャッシュ管理がサポートされました! #AWSSummit
昨日、Aurora PostgreSQL においてフェイルオーバー後のパフォーマンスを改善するクラスタキャッシュ管理に関する機能アップデートがありましたので紹介します。
何がうれしいのか
Amazon Aurora はマスターのインスタンスで障害が発生した場合、リードレプリカのインスタンスが昇格するかたちでフェイルオーバーすることが出来ます。これまでクラスタキャッシュ管理がない場合に、フェイルオーバーによって昇格したインスタンスには、マスターが使用していたウォームキャッシュは引き継がれていないため、ストレージから読み込む必要がありパフォーマンスが一時的に低下してしまいます。
クラスタキャッシュ管理のサポートによって、あらかじめ指定されていた特定のリードレプリカにのみウォームキャッシュを同期することが出来るようになりました。これにより、フェイルオーバーによって昇格した場合でも直ちにパフォーマンスを発揮することが可能となりました。
AWS Summit Tokyo 2019 Day2 のセッション「サービス責任者が語る Amazon Aurora MySQL/PostgreSQL の詳細と内部構造」の中で紹介されたパフォーマンス測定によれば
- クラスタキャッシュ管理がない状態でフェイルオーバー
- 32秒でデータベース起動
- パフォーマンスが90%回復するっまでに340秒
- クラスタキャッシュ管理がある状態でフェイルオーバー
- 32秒でデータベース起動し、パフォーマンスは回復
(お察しのとおり記事タイトルの「32秒」はココから来ています。)
ほぼデータベースの起動と同時にもとどおり、といった内容ですね。すばらしい。
【AWS Summit Tokyo 2019 セッションレポート】サービス責任者が語る Amazon Aurora MySQL/PostgreSQL の詳細と内部構造 #AWSSummit
試してみる
こんな数字みせられたら設定しておかない理由はないですね。ということで設定手順を公式ガイドに従ってまとめました。(本記事では設定手順までであり、パフォーマンスの検証などは行っておりませんので、あしからず)
検証環境
- 東京リージョン
- Aurora PostgreSQL
- db.r5.large
注意点
クラスタキャッシュ管理の設定はクラスターパラメータグループで行います。デフォルトのパラメータグループでは値の変更ができないため、デフォルト以外のクラスターパラメータグループが必要です。
クラスタキャッシュ管理の有効化
RDS ダッシュボードから[パラメータグループ]を開き、対象の Aurora PostgreSQL クラスターが使用しているクラスターパラメータグループを選択し、[パラメータグループアクション]から[編集]をクリックします。
apg_ccm_enabled
の値を 1 に設定し、[変更の保存]をクリックします。
書き込み DB の優先順位設定
RDS ダッシュボードから対象の Aurora PostgreSQL クラスターを展開し、書き込み DB インスタンスを選択。[変更]をクリックします。
フェイルオーバーパネルの優先度を[範囲-0]に変更し、直後に適用するには[すぐに適用]を選んで[DB インスタンスの変更]をクリックします。
読み込み DB の優先順位設定
同じ Aurora PostgreSQL クラスターから、1つの読み込み DB インスタンスを選択。[変更]をクリックします。
同様にフェイルオーバーパネルの優先度を[範囲-0]に変更し、直後に適用するには[すぐに適用]を選んで[DB インスタンスの変更]をクリックします。
今回は読み込み DB が1台でしたが複数ある場合は、この作業によって書き込み DB インスタンスに昇格される順序が上位になります。
設定は以上です!
さいごに
このアップデートでどれくらい改善されるのかなーと疑問に思ってたところ、本日の Summit で具体的な数字が出てきて「へぇー!」と思ったので記事にしてみました。Aurora PostgreSQL のフェイルオーバー直後のパフォーマンスでもしお悩みの方がおられましたら、試してみてはいかがでしょうか。
以上!大阪オフィスの丸毛(@marumo1981)でした!